/// <summary>
/// An interface to a block renderer.
/// </summary>
class IBlockRenderer
{
public:
	/// <summary>
	/// Called to render this block. Must be overridden by implementors of this interface.
	/// </summary>
	/// <param name="schematic">The schematic this block is a part of.</param>
	/// <param name="renderer">The renderer, which can render primitives.</param>
	/// <param name="block">The block being rendered.</param>
	/// <param name="position">The position of this block in the world.</param>
	virtual void Render(Schematic &schematic, IChunkRenderData &renderer, const Block &in block, const Point3i &in position) = 0;
}

/*! \page gettingstarted Getting Started
  \tableofcontents
  So you want to write block renderers for MSchemV? That's cool, most people do. Most people I asked, anyways.
  Then they told me to get out of their houses. I don't know why I ask those people anything. Please note that beyond this point,
  if you don't have a basic understanding of programming, you likely will not understand anything that is listed below.
  \section basic The Basics
  We need to start by setting some words up. There are only a couple to add to your personal dictionary.
  - "Renderer" = a data type which can render a Block, and inherits from IBlockRenderer.
  - "Module" = a set of executable code which includes a function for adding block renderers to the internal list
  Seems rather simple. You make a module which creates renderers. Simple.
  \section modules Modules
  Modules are organized into folders inside the "renderers" folder of your MSchemV installation. They contain all of the
  code required to identify and initialize itself, as well as any references to other modules' renderers it may need.
  Modules only need two files to function: ModuleInfo.as and Module.as. ModuleInfo.as is a special file which is loaded before anything else.
  It contains a \ref GetInfo "single function named GetInfo", which returns the information that the module requires to load and information about the module itself.
  The file should only contain this function. An example of such a file follows.
  \code{.cpp}
	// Returns a ModuleInfo which defines this
	// module.
	ModuleInfo GetInfo()
	{
		return ModuleInfo
				(
					"Minecraft Block Renderers",	// Module name (any characters)
					"mcdefaultblocks",				// Module friendly name (lowercase only, no symbols)
					"1.0",							// Module version
					"Paril",						// Module author
					""								// Hard dependencies (semicolon separated friendly names)
				);
	}
  \endcode
  This file alone will allow MSchemV to register the module, however you have not created the actual guts of the program yet.
  Keep in mind that ModuleInfo.as is special in that it is <b>discarded</b> and not loaded during the full pass. The actual module initialization
  should be done in a new file, which for the purpose of this example we will name "Module.as". This file should only contain one function: \ref Init.
  \code{.cpp}
	// Initializes and creates renderers.
	void Init(RendererBase &renderer)
	{
	}
  \endcode
  If you just keep these two files, and run MSchemV, your module will now have loaded into MSchemV. Congratulations, you have
  created a module! It doesn't do anything, though, so let's try to make things happen.
  \section renderer Block renderers
  In order to actually do things, we need to create a block renderer. A block renderer is a class which implements the IBlockRenderer interface. This is
  a pretty simple task. Let's define a very simple block renderer here, which accepts a texture that you feed to it.
  \code{.cpp}
	class ExampleBlockRenderer : IBlockRenderer
	{
		ITexture Texture;

		ExampleBlockRenderer(ITexture texture)
		{
			Texture = texture;
		}

		void Render(Schematic &schematic, IChunkRenderData &renderer, const Block &in block, const Point3i &in position)
		{
		}
	}
  \endcode
  If you feel lost by this point, you will definitely want to grasp C++ or C# a bit more before continuing. You can also try reading the AngelScript
  documentation, if that helps any. Anyways, now we have a renderer that can be instantiated by our Init function above, and passed back to
  MSchemV to be registered as a block renderer. Save this class as "ExampleBlockRenderer.as". If you wish to allow use of this renderer from other modules,
  you can place "shared" prior to "class", which will name it a shared class, and as such allow it to be used in \ref harddep.
  Keep in mind that this renderer doesn't actually DO anything yet; let's go back and edit the Init function in Module.as:
  \code{.cpp}
	// Initializes and creates renderers.
	void Init(RendererBase &renderer)
	{
		ITexture terrain = renderer.GetTexture("terrain.png");

		AddRenderer(1, ExampleBlockRenderer(terrain));
	}
  \endcode
  Those familiar with C++ or similar languages don't need much explanation, but basically, we request the "terrain.png" texture from the base renderer. Following that,
  we create an instance of our ExampleBlockRenderer, send it the texture we just grabbed, and call \ref AddRenderer - which adds the block instance to the dictionary,
  and will call that renderer to render the block ID listed. Note that you <em>can</em> re-use the same instance of the renderer to render different blocks, however that isn't
  required in the scope of this sample. Now, we have a renderer that still doesn't do anything, but it's registered in the program. It will now render that block - and, if you
  check the statistics inside MSchemV, you can see that that block is now registered by your module.
  \subsection box Rendering a box
  We have a blank renderer now we can use for anything.. let's use it to draw a box! Open up ExampleBlockRenderer.as that you created earlier, and let's modify the Render function.
  \code{.cpp}
	void Render(Schematic &schematic, IChunkRenderData &renderer, const Block &in block, const Point3i &in position)
	{
		renderer.Draw(Box(Texture).SetAll(Point2i(0, 0)));
	}
  \endcode
  Save this, open up MSchemV, check for errors - in theory, no error should be generated. Open up a test schematic, and voila - blocks with id 1 are now rendered as a gray-spotted box!
  Please check the Box documentation for the other functions that a box can do, such as assigning different colors, sizes, positions & insets of various faces and/or the box itself.
  \subsection face Rendering a face
  If you want total control over how the object is rendered, you can use the Face class directly. This allows you to create & render a single plane.
  You can also set the second argument of \ref IChunkRenderData::Draw(const Face &face, const bool &reverse) to true if you wish to draw both sides of the face, rather than having to draw the face twice.
  \section dependencies Dependencies
  Dependencies in MSchemV's scripting format are split into two categories: \ref lightdep and \ref harddep. Depending on how you wish to
  access (or allow access to) other scripts, you will need to pick which one of the two you need to use and/or support.
  \subsection lightdep Light Dependencies
  Light dependencies are optional dependencies that can be resolved at run-time via two built-in functions: \ref IsModuleLoaded and \ref CreateModuleRenderer. These two functions
  allow you to check, and subsequently create, a renderer from a module that may or may not be loaded. This is essentially a run-time conditional, and lets you change the flow
  of your module if certain modules are there or not. You can use this to create proper support for other modules, and optionally prevent loading blocks which may conflict or
  may not be required if said modules are not loaded. You can also instantiate renderers from other modules via this function, which is helpful to prevent tons of re-typed code.
  The maker of a module may have (intentionally) left his classes non-shared to encourage that you instead link to his classes via a light dependency, in case they change in the future.
  \subsection harddep Hard Dependencies
  Hard dependencies are compile-time dependencies that are required by your module to run properly. In \ref modules, we created a ModuleInfo instance. The last argument of that constructor
  allows you to define semicolon-separated friendly names of modules which <b>must</b> be loaded prior to your module getting initialized. If they are not loaded, your module will simply
  be skipped, and a note will be added to the log about why the module was not instantiated. Hard dependencies are required if you are going to be inheriting from classes that other
  modules are providing you. Since you cannot be guaranteed at compile time that said class is available, you must declare them as a hard dependency, else you may face errors if users
  use your module without the module that it requires.
*/